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REMARKS/ARGUMENTS 

This Amendment and the following remarks are intended to fully respond to the Office 
Action dated August 10 5 2005. In that Office Action, claims 1-13 were examined, and all were 
rejected. More specifically, claims 9, 1 1, and 13 stand rejected under 35 U.S.C. § 1 12, second 
paragraph, as being indefinite for failing to particularly point out and distinctly claim the subject 
matter which Applicant regards as the invention; and claims 1-12 stand rejected under 35 U.S.C. 
§ 102(a) as being anticipated by the article "Performance of the IBM General Parallel File 
System' 1 by Terry Jones, Alice Koniges, and R. Kim Yates (hereinafter, "Jones"). 
Reconsideration of these rejections, as they might apply to the original and previously amended 
claims in view of these remarks, is respectfully requested. 

In this Response, no claims have been amended, added, or canceled. 

Claim Rejections - 35 U.S.C. S 112 

Claims 9, 1 1, and 13 stand rejected under 35 U.S.C. § 1 12, second paragraph, as being 
indefinite for failing to particularly point out and distinctly claim the subject matter which 
Applicant regards as the invention. Determining whether a claim is indefinite "requires an 
analysis of whether those persons skilled in the art would understand the bounds of the claim 
when read in light of the specification." Credle v. Bond , 25 F.3d 1566, 1576 (Fed. Cir. 1994). 
The degree of precision necessary is a "function of the nature of the subject matter" at issue. 
Miles Labs., Inc. v. Shandon, Inc., 997 F.2d 870, 875 (Fed. Cir. 1993). 

The Examiner rejected claims 9, 1 1, and 13 for indefiniteness, stating that "[i]t is 
indefinite as to what 'advisory 1 distinctly claims." Examiner's Arguments, Office Action, 
8/10/2005, p. 2. 

Applicant respectfully disagrees that the term "advisory" is indefinite and offers the 
following discussion for purposes of clarification. When read in light of the specification, a 
person of ordinary skill in the art would understand that, according to at least one embodiment of 
the invention, the term "advisory" is used as an adjective to modify the term "lock" to describe a 
lock property, Le., the "status" of the lock. Line 1 5, p. 4. A reading of the specification shows 
that the term "advisory" is used according to its plain language meaning. Thus, the status of a 
lock is "advisory," as opposed to "mandatory," when the lock is of such type that it may be 



5 



Application No. 09/992,644 



" either honored or ignored by other client computer systems." Lines 15-16, p. 4 (emphasis 
added). In other words, the lock is "advisory" in that another client computer system may decide 
whether to honor the lock or to ignore it and access the resource requested. Lines 17-18, p. 7; 
lines 22-23, p. 20. In contrast, a "mandatory" lock is of such type that it "may not be ignored." 
Line 10, p. 5 (emphasis added). Thus, where the lock is "mandatory," a conflicting access 
request will be denied. Id. On the other hand, a lock is "advisory" in that it allows another client 
computer system to "decide" whether or not to honor it. In this sense, the lock is merely 
"advisory" in that there is " no requirement to honor the lock." Lines 21-22, p. 3 (emphasis 
added). 

Because the degree of precision necessary for an adequate claim is commensurate with 
the nature of the subject matter at issue, see Miles Laboratories, Inc. , and because a person 
skilled in the art would understand the bounds of claims 9, 1 1, and 13 in light of the extensive 
disclosure provided in the specification portion of this application, Applicant respectfully 
requests that the Examiner reconsider the 35 U.S.C. § 1 12, second paragraph, rejections of 
claims 9, 11, and 13. 

Claim Rejections - 35 U.S.C. § 102 

Claims 1-12 stand rejected under 35 U.S.C. § 102(a) as being anticipated by Jones. 
Applicant respectfully traverses the § 102(a) rejections because the Examiner has failed to state a 
prima facie case of anticipation. A prima facie case of anticipation can be met only where the 
reference teaches each and every aspect of the claimed invention. See MPEP §§ 706.02 & 2136. 
Further, because the reference cited by the Examiner is a "printed publication," Applicant 
respectfully traverses the § 102(a) rejections because the document is not descriptive and 
enabling as required by § 1 12, first paragraph. See In re Hoeksema, 399 F.2d 269, 273, 158 
USPQ 596, 600 (CCPA 1968). 

The present invention, as defined in the claims, relates generally to distributed computing 
environments and particularly to a method and system for creating and maintaining lock 
properties for a resource or object in a distributed environment. This method and system may be 
implemented in a software operating environment; however, other operating environments may 
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be used as well. A distributed environment allows multiple clients to share many different 
computer resources. There are many advantages to sharing computer resources, such as the fact 
that where software-related resources are shared, only one resource needs to be created, updated 
and maintained. Although there are benefits to sharing resources, a locking scheme is useful to 
prevent "lost update" problems from arising where two or more users modify a shared resource at 
the same time. In this regard, lock properties are used to limit the availability of a locked 
resource to other client computer systems. Where the availability of a resource is limited, other 
client computer systems may be restricted to reading, writing, or deleting (or any combination 
thereof) the object or resource. Although limits can be placed on the availability of a resource, 
the invention provides for lock properties which allow other client computer systems to 
simultaneously hold, or share, equivalent locks. The lock properties claimed in this invention 
include, but are not limited to, the use of new shared lock types, such as shared read locks, 
shared write locks, and shared delete locks. The present invention is not limited to exclusive 
write locks and shared write locks but, instead, supports open sharing modes wherein, by way of 
example, a user may prevent another client from deleting a resource while at the same time 
allowing that same client to read the resource. Further, the invention provides for the locks to be 
advisory or mandatory in status. With respect to advisory locks, other client computer systems 
may decide whether to honor or ignore the locks. 

While the present invention relates primarily to sharing software-related resources, the 
Jones article relates exclusively to a hardware-based method of data access that is designed to 
increase the throughput, and throughput rates, of data by providing for parallel file systems. See 
Jones , § 2 ("The [General Parallel File System (GPFS)] architecture was designed to achieve 
high bandwidth for concurrent access to a single file . . . [t]he intended platform for this file 
system is IBM's line of massively parallel computers, the RS/6000 SP, and performance is 
achieved with commodity disk technology. The RS/6000 SP line of machines are general 
purpose, high[-]end computers which scale to thousands of processors."). See also id at § 2.3 
("[T]he degree of scalability is probably the most unique feature of GPFS. This design permits a 
file to be striped across a system-administrator-defined number of server nodes. Not only does 
this provide higher aggregate read and write performance, it also permits larger files and file 
systems."). 
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With respect to claim 1 , Jones teaches neither a "lock having a predetermined type, 
wherein the predetermined type provides availability to other client computer systems for 
predetermined purposes, " nor a "lock token related to the created lock to the requesting client 
computer system.' 1 Jones also fails to teach that the "request originates from a requesting client 
computer system." 

First, while Jones refers to a general locking scheme for accessing a file, this scheme 
relates exclusively to system software, as opposed to application or network software. System 
software relates to the underlying operating system of the computer and is thus hardware-related 
in that it "controls the workings of the computer." Microsoft Computer Diet. 489 (5th ed. 2002). 
System software is therefore a distinct type of software from application and/or network 
software. See id. (" Two main types of software are system software (operating systems), which 
controls the workings of the computer, and applications, such as word processing programs, 
spreadsheets, and databases, which perform the tasks for which people use computers. Two 
additional categories, which are neither system nor application software ... are network software 
..." (emphasis added)). Because Jones relates to a hardware-and-system-software-based method 
of data access, Jones relates to a distinct field of art from that of the claimed invention. 
Accordingly, while Jones may refer to a "lock" and a "token," it inherently must attach a 
different conceptual meaning to these terms than that attached by the present invention. Any 
similarities in the selected terminologies of Jones and the claimed invention must therefore be 
considered in the context of their separate, and distinct, inventions. Further, because Jones 
relates exclusively to a hardware-based method of data access for increasing the throughput, and 
throughput rates, of data by providing for parallel file systems, it is Applicant's view that the 
Jones reference cannot be considered to be enabling and/or descriptive with respect to the type of 
invention embodied by the claims of the present invention. Applicant therefore respectfully 
traverses the § 102(a) rejections because Jones does not satisfy the requirements of § 112, first 
paragraph. See In re Hoeksema . 

Second, unlike the present invention, Jones fails to relate to "other client computer 
systems." Because Jones involves the GPFS, the computer systems to which it refers are not 
separate systems but, instead, are systems which are a part of the GPFS system as a whole. See 
Jones , § 2.1 ("GPFS is implemented as a number of separate software subsystems or services. 
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Each service may be distributed across multiple nodes within an SP system" (emphasis added)). 
Therefore, Jones does not teach request or lock issues associated with "other client computer 
systems" but, instead, defines operations for the computer systems which are a subpart of the 
overall GPFS system. On the other hand, a key feature of at least one embodiment of the 
claimed invention is its provision for allowing for shared resources in a distributed environment 
in which multiple, and possibly separate and unrelated, client systems may share resources. In 
contrast, Jones relates to software subsystems and nodes which are within the overall GPFS 
system. See id. at § 2.1 ("There is one such copy of the [token manager] mmfsd running within 
the entire SP parallel computer " (emphasis added)). 

Third, Jones fails to teach that the locks are !, creat[ed]" upon a request from a client 
computer system. Various embodiments of the claimed invention provide for the creation of 
lock objects by application programs or the services layer. The client system includes requests 
for the type of lock(s) to be created during that client's use of the object. On the other hand, 
Jones does not disclose "creating" a lock upon request of another computer system but, instead, 
refers only to whether a lock exists in the item being accessed in the first instance. See id. at § 
2.1 (referring only to whether the application "holds" a lock). 

Fourth, the present invention provides for locks of a "predetermined type," wherein 
availability is provided to other client computer systems for "predetermined purposes." In this 
regard, the invention provides both for exclusive locks, which do not allow any other clients to 
access the application for any purpose, and for shared locks which allow other clients to access 
the application for limited, and defined, purposes. In fact, a key feature of the claimed invention 
is its provision for shared locktypes, such as nosharewrite, nosharedelete, and noshareread locks. 
For example, with nosharedelete locks, two separate clients may read or write to the same 
application (although neither client may perform deleting operations with this type of lock). 
Jones, on the other hand, does not provide for any shared locktypes. To the contrary, Jones 
expressly states: "[I]f two separate nodes write to the same file, and if the writes are overlapping, 
the overlapped region must be either entirely from node A or entirely from node B ." Id. 
(emphasis added). The present invention thus teaches in a different direction from that of Jones 
because, according to particular expressed embodiments of the claimed invention, the purpose of 
certain predetermined locktypes is their ability to allow multiple clients to "share" resources and 
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to thus allow for modifications of a given resource by more than one client computer system, Le., 
to prevent "lost update" problems which may arise when multiple clients modify a resource 
simultaneously. While Jones allows for "one task [to] be granted to write or read access to a 
portion of a file, and other tasks [to] be granted read or write access to other portions of the same 
file," id. at § 2.3, Jones still teaches in a different direction than the present invention because 
while the "same file" may be accessed, the different access grants are directed to "other portions" 
of that file. 

In addition, with respect to claim 11, Jones fails to teach an "advisory lock." Applicant 
incorporates by reference the preceding discussion regarding the distinct fields of art of Jones 
and the present invention, as well as regarding the different direction of the teachings of the 
claimed invention as compared to Jones. In addition, Applicant notes that Jones neither teaches 
"if the resource is locked by another computer system with a conflicting advisory lock then 
denying access if the requesting client computer system honors advisory locks," nor "performing 
the access if the requesting client computer system does not honor the advisory lock or if the 
resource is not locked with a conflicting lock." As discussed above, a lock is "advisory" when it 
is of such type that it may be " either honored or ignored by other client computer systems." 
Lines 15-16, p. 4 (emphasis added). Jones makes no mention, either explicitly or implicitly, of 
an advisory lock. To the contrary, the locks described by Jones refer only to locks of a 
mandatory type. Jones provides: "On every write access, the mmfsd determines if the 
application holds a lock that permits the right to modify the file. If this is the first write for this 
node and for this file, a write token must be acquired." Jones , § 2.2 (emphasis added). 

For at least the aforementioned reasons, Applicant respectfully requests reconsideration 
of the rejections to claims 1 and 1 1 in view of Jones as these claims are believed to recite the 
present invention in a manner which is patentably distinguishable over Jones. In addition, claims 
2-10 and 12 are also believed to be patentable over Jones as these claims depend from the 
allowable base claims 1 and 1 1 . 

Conclusion 

This Amendment fully responds to the Office Action mailed on August 10, 2005. It is 
recognized that the Office Action may contain arguments and rejections that are not directly 
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addressed by this Amendment due to the fact that they are rendered moot in light of the 
preceding arguments in favor of patentability. Hence, the failure, if any, of this Amendment to 
directly address an argument raised by the Examiner should not be interpreted as reflecting 
Applicant's belief that such argument, if any, has merit. Furthermore, the claims of the present 
application may include other elements, not discussed in this Amendment, which are not shown, 
taught, or otherwise suggested by the art of record. Accordingly, the preceding arguments in 
favor of patentability are advanced without prejudice to other bases of patentability. 

It is believed that no further fees are due with this Amendment. However, the 
Commissioner is hereby authorized to charge any deficiencies or credit any overpayment with 
respect to this patent application to deposit account number 13-2725. 

In light of the above remarks and amendments, it is believed that the application is now 
in condition for allowance, and such action is respectfully requested. Should any additional 
issues need to be resolved, the Examiner is requested to telephone the undersigned to attempt to 
resolve such issues, if any. 



Respectfully submitted, 






PATENT TRADEMARK OFFICE 



P.O. Box 2903 
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